Date: Fri, 12 Nov 93 04:30:02 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #294 To: tcp-group-digest TCP-Group Digest Fri, 12 Nov 93 Volume 93 : Issue 294 Today's Topics: FTP client on SysV TLI (was: NOS FTP Bug) KA9Q NET problem once more On the merits of KISS Re- TCP broadcast storm Three things (3 msgs) WinQVT/Net ( was Campus Net ) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 12 Nov 1993 10:16:34 +0200 (EET) From: mea@mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]") Subject: FTP client on SysV TLI (was: NOS FTP Bug) To: ssampson@sabea-oc.af.mil (Steve Sampson) > brian@nothing.ucsd.edu says: > >In one sense, it's a good idea to be conservative what you send in order > >to avoid breaking existing software. Yet progress must be made; at some > >point you have to make changes - and these changes might expose > >previously-unknown-to-be-broken software. > > - Brian I should check what exactly has been going on, but these things sound very much like my experiences with NIC.FUNET.FI, if you know the machine :) > While I agree that new NOS routines can't be responsible for working with > AT&T machines, maybe we can at least make NOS work per the RFC, and then any > problems with AT&T users can be answered with "tough tits, get yourself > something that works". :-) > > By the way, the Sun machine at ds.internic.net also sends out 220- on every > line just like NOS, so maybe this is the way everyone is interpreting the RFC?? As a startup banner, they throw at you a screenfull of 220 replies, and it happens in accordance with FTP's protocol specs: nnn- starts multiline response more multiline response lines nnn ends multiline response Now I know that several older programs (including BSD ftp-client) made assumption that there won't be more than some small number of those lines. Usually at most 4 lines.. Such assumption is, of course, wrong. > P.S. Anyone who has the BSD ftp and ftpd ported to the 3B2 and SysV 3.2, > I wouldn't mind a copy. Just the thought of all the changes to the > include files makes me tired :-) If somebody ports the DNS resolver to TLI, that helps a LOT! I might do it eventually too, but I have so many other more urgent things to do (well, which directly affect my activities..) > --- > Steve, N5OWK /Matti Aarnio OH1MQK ------------------------------ Date: Thu, 11 Nov 1993 07:32:26 -0600 From: stevej@cris.plano.gov (Steve Jones) Subject: KA9Q NET problem once more To: andy@mimuw.edu.pl, tcp-group@ucsd.edu I noticed that behavor whenever I got REAL short on memory. I went to OS/2 to get a bigger dos box Steve wb5sgn@wb5sgn.ampr.org stevej@cris.plano.gov ------------------------------ Date: Thu, 11 Nov 1993 15:18:53 -0600 (CST) From: Steve Sampson Subject: On the merits of KISS To: TCP-Group@UCSD.Edu jhays@hays.org writes: >I've been thinking for some time that a new ROM for TNCs which does SLIP >instead of KISS might be in order. When I started playing with the X-1 TheNet this thought also crossed my mind. The basis of KISS is that it adds a command byte to SLIP and can then be used to modify TNC parameters. But since the same parameters can be adjusted through connection to the X-1, the command byte of KISS becomes redundant. Thus even KISS is not needed, as SLIP would be good enough. >but on the serial port it would look like a SLIP Point-to-Point connection I agree. This would really be neat. Instead of the KISS code in the TNC (module) a better routine would be an AX.25<->SLIP routine. Since the X-1 has ARP, it would seem that it would be useful to just strip the AX.25 layer and perform SLIP. Same for the SLIP to AX.25 module which would convert the IP address to the TNC callsign. The advantage as I see it, is that you no longer need the AX.25 code in NOS, but the disadvantage is that the TNC code becomes so large that even 512k ROM is too small. The Gracilis boards perform this very well I understand, but they would have to be rated as something more than a TNC. Actually my idea of a good TNC would be the X-1 code minus the Net/Rom stuff. In this case all you have is a "dumb" router, but that's all you need. So given choices I would say see if you can get by with modifying X-1 by deleting KISS, do that, or second just throwing out the Net/Rom part if it comes to that. (that stuff is too slow anyway). --- Steve ------------------------------ Date: Thu, 11 Nov 1993 08:33:22 -0800 From: braden@ISI.EDU (Bob Braden) Subject: Re- TCP broadcast storm To: postel@ISI.EDU, karn@qualcomm.com *> From karn@qualcomm.com Wed Nov 10 21:17:57 1993 *> Date: Wed, 10 Nov 93 21:17:02 -0800 *> From: karn@qualcomm.com (Phil Karn) *> To: postel@ISI.EDU *> Cc: braden@ISI.EDU, ietf-hosts@ISI.EDU, TCP-Group@ucsd.edu, *> MGauthier@iit.nrc.ca *> In-Reply-To: Jon Postel's message of Mon, 8 Nov 1993 08:43:10 -0800 <199311081643.AA24710@zephyr.isi.edu> *> Subject: Re- TCP broadcast storm *> Content-Length: 553 *> X-Lines: 11 *> *> This confusion between the Internet itself and the hosts attached to *> it continues. Last week, during the Houston IETF, the New York Times *> carried an article titled "Traffic Jams on the Information Highway" *> (or words to that effect, this is from memory). The article was *> clearly about the extreme loads that certain popular *server machines* *> on the net have been experiencing, but the title metaphor obviously *> gives the (mis)impression that the NSF backbone communication links are *> overloaded. As far as I have been able to observe, they are not. *> *> Phil *> *> Phil, Yeah, that was noted by a number of people. Dave Sincoskie (you know him, I suspect!) twigged John Markoff personally about it, and John said essentially that yes, he understood the distinction, but as a user he did not care. The main point of the article was the need to charge for services, and I guess he thought the issue of host/net services was secondary. Bob ------------------------------ Date: Fri Nov 12 14:22:52 1993 From: iiitac@pyramid.swansea.ac.uk Subject: Three things To: tcp-group@ucsd.edu 1. G8BPQ does indeed include a packet driver that provides an AX.25 packetdriver interface but not the SLIP/ETHER ones most software needs. 2. A SLIP TNC is overkill. Far more effective would be a DOS packetdriver akin to etherslip but doing etherax25 conversions. This would entail squashing ax.25 calls to 6 byte addresses (code is in the sun ax.25 driver already) and prepending AX.25 headers and LAPB UI followed by a protocol byte of either IP or ARP. For someone with reasonable PC assembler skills (not me!) I can't see this being a horrific job. The final result would let you run stuff like QVTNET over radio transparently - and NCSA telnet, Waterloo FTP etc. 3. Is there a summary of differences between ccitt LAPB and the AX.25 LAPB anywhere - or would someone be prepared to email me a list. I've got a very nice compact implementation of LAPB I'm playing with, and turning it into an AX.25 stack would be quite useful. [I know about the AX.25 headers etc I'm interested in state machine differences and things like pthresh which don't seem to be in ccitt LAPB. Alan GW4PTS@GB7SWN//iiitac@pyr.swan.ac.uk ------------------------------ Date: Thu, 11 Nov 93 11:22:09 -0800 From: jhays@hays.org (John D. Hays) Subject: Three things To: iiitac@pyr.swan.ac.uk Alan, Your argument (which follows) pre-supposes that everybody who runs AX.25 uses a PC with DOS ... There are many other systems out there besides DOS, many of which have a SLIP feature already available to their TCP/IP stack [for example in my home network I have DOS, Windows, Domain/OS, NEXTSTEP, and hopefully LINUX before long --- all of which have slip capable programs, a SLIP TNC should allow any of these machines to go directly on to the AX.25 network without modifying system code]. A SLIP TNC would provide a simple way to connect any SLIP capable machine's IP stack to communicate on the AX.25 encapsulated IP network. John KD7UW Begin forwarded message: From: iiitac@pyr.swan.ac.uk Via: uk.ac.swansea.pyramid; Thu, 11 Nov 1993 16:24:56 +0000 Date: Fri Nov 12 14:22:52 1993 Subject: Three things 2. A SLIP TNC is overkill. Far more effective would be a DOS packetdriver akin to etherslip but doing etherax25 conversions. This would entail squashing ax.25 calls to 6 byte addresses (code is in the sun ax.25 driver already) and prepending AX.25 headers and LAPB UI followed by a protocol byte of either IP or ARP. For someone with reasonable PC assembler skills (not me!) I can't see this being a horrific job. The final result would let you run stuff like QVTNET over radio transparently - and NCSA telnet, Waterloo FTP etc. Alan GW4PTS@GB7SWN//iiitac@pyr.swan.ac.uk ------------------------------ Date: Fri, 12 Nov 93 06:34:01 GMT From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW) Subject: Three things To: tcp-group@ucsd.edu What about the backoff timers that are in NOS that aren't in various other TCP/IP programs? I too would like to run WinQVT, Linux, etc... over packet, but it's not designed for packet radio environment. That's part of the reason why people are putting NOS systems between their tnc's and their other TCP/IP programs. Kinda curious, how does the AX.25 stuff for the Sun work? Does it work effectively in a heavily shared frequency like most major cities have to deal with? I know the way that pings are done in most Unix systems make it not very usable for packet and it seems to just key the transmitter for long periods of time. I'm currently running NOS in MS Windows (yuck, but it works) and I sometimes run 2 versions of NOS. Is there a way for them to talk to each other or for something like WinQVT to talk to NOS internally? This might be a quick way to put something other than NOS on the air for the UI but let something designed to operate in packet handle the tnc's, and on the same computer too. Ron ------------------------------ Date: Thu, 11 Nov 1993 09:52:27 -0600 From: miltonm@inetnode.austin.ibm.com (Milton Miller) Subject: WinQVT/Net ( was Campus Net ) To: jhays@hays.org, kf5mg@kf5mg.ampr.org John D. Hays wrote: > I've been thinking for some time that a new ROM for TNCs which does SLIP > instead of KISS might be in order. There would probably need to be a loader > program of some type that downloaded Callsign, PARAMs, etc. to the TNC, but on > the serial port it would look like a SLIP Point-to-Point connection ... Then > various implementations of TCP/IP which speak SLIP could access the AX.25 > encapsulated IP network.... Does TheNet X1H have this capability? milton ------------------------------ End of TCP-Group Digest V93 #294 ****************************** ******************************